Mobile phones and services on mobile handsets (as used herein the terms “mobile handsets” and “mobile terminals” also refer to embedded devices in, e.g., PCs, laptops, vehicles, etc.) have had a remarkable evolution over the last few decades. When 3GPP (third generation partnership project) standardized Global System for Mobile communications (GSM) and later Third Generation (3G) during the late 80's and 90's, circuit switched telephony and later Short Message Service (SMS) were pretty much the only services available. Recently, mobile handsets and their networks have evolved to powerful devices capable of running local application and browser based services, connected to a network providing a bandwidth high enough for TV and interactive multimedia. With the increasing bandwidth, and corresponding need to provide a feasible technical platform and transport technology for multimedia services, packet switched networks using Internet Protocol (IP) as the fundamental technology is becoming the dominating platform for mobile services.
With the increasing bandwidth, advanced mobile handset and IP connectivity, functionality that earlier has been implemented as tightly integrated functionality in the operator's network with thin clients (i.e., clients having handsets with poor processing and memory storage capabilities that use control channels for communication with the network), is today also available for applications located in the IP domain in the operators network or even outside the operators network, for the relatively thicker client (i.e., clients having handsets with competitive processing capabilities and large memory storage). As the thicker clients' communications with a server in the network often requires (i) information about the network and/or (2) native functionality existing in the handset to function correctly, there are interfaces and protocols which provide this type of information. The functionality and information is to a large extent what is often referred to as the control plane, while the communication between a client on the handset and a server in the network based on packet based technology (typically IP) usually is referred to as the user plane.
The user plane and control plane architecture of a handset 80 is discussed with regard to FIG. 1, which is disclosed in U.S. patent application Ser. No. 12/346,066, entitled “Abstraction Function for Mobile Handsets,” to J. Bolin et al, the entire content of which is incorporated herein by reference. FIG. 1 illustrates a conceptual view of a typical mobile handset 80. Therein, a bottom layer 100 represents the control plane, which provides the core functionality of the mobile handset 80, e.g., communications with the mobile phone via control signalling used to manage the connection, mobility and also some of the basic services (e.g., call control and SMS). On top of the control layer 100 may be the operating system OS 102, which manages the phone's functionality and provides the interface to functionality for applications and clients in the user plane 104. Clients and/or applications 106, such as browsers, calendar and games, are examples of services implemented in the user plane 104, on top of the operating system 102.
The mobile phones may also include a Java Virtual Machine (JVM) 110. The JVM 110 may run on top of the operating system 102 and enables Java based applications to run on the handset 80. There are various JVMs which are adapted for platforms with different computing capacity and characteristics. One common JVM for mobile handsets is known as the Java Micro Edition, J2ME. J2ME provides a number of application programming interfaces (APIs) for application developers to use when developing applications for mobile handsets.
Thus, the J2ME environment is advantageous for those developers that are not associated with a certain operator but intend to deploy applications on handsets subscribing to a certain operator. The exemplary embodiments describe how to allow these developers to access the sensitive information from the control plane when the operator has a relationship with the developers and how to deny other developers and/or operators to access the information in the control plane when these later developers and/or operators are not authorized to access that data. Java may be used, for example, to reduce the amount of customization of applications associated with different handset models, since the Java APIs used for different handset models are relatively similar to one another. Other OS may be used instead of JVM as discussed later.
As mentioned earlier, the user plane 104 is disposed above the operating system 102 and Java 110. The user plane 104 may include one or more applications and/or clients 106. One difference between a client and an application may be that an application provides a service to the user while the client may perform a function for the network and not a direct service to the user, i.e., the client has a low level functionality to the user. These applications and clients 106 may use the communication channels of the user plane for exchanging data with the operator's network or with third parties. Such communication channels may be General Packet Radio Services (GPRS) and TCP/IP. These channels may be used to communicate with application and content servers 112, inside the operator's network (control domain) or servers 114, which are outside the operator's domain (e.g., Internet servers).
Applications 106 may access information and functionality in the handset 80 either via the operating system 102 or Java 110. Additionally or alternately, a natively installed client 106, such as the OMA (Open Mobile Alliance) SUPL (Secure User Plane Location) client, may be provided in the user plane to access information in the control plane. Thus, an application or client 106 in the handset 80 can extract, via APIs in the operation system (OS) 102 and Java 110, but also by using native clients such as the OMA SUPL 106, information from the control plane or invoke functionality and send this to servers 114 outside the operator's network 112.
There are a number of reasons why the user plane/control plane architecture is being supported by most actors in the business. One is that third parties will start to develop applications and, just as in the case with Internet, this will be helpful to the expected success of future systems. Another is that IP provides a technology platform where it is cheaper to deploy functionality. This is to a large extent due to economy of scale, as technology also used by the IT industry is cheaper than traditional telecom technology.
However, the existing interfaces expose the native functionality and network information in such systems to the third parties without offering the operator of the network a capability to selectively provide that information to desired third parties, i.e., parties that are entitled to receive that information. In other words, the existing interfaces could not offer the network's operator the possibility to selectively decide which third party to access the network information and/or the native functionality. This selectivity may be decided, for example, based on a license agreement between the third party and the network's operator.
For example, the OS typically provides information regarding most of what is available in the handset. Symbian, Nokia Series 60, Windows Mobile and Linux are examples of OSs that provides interfaces for services and information in the control plane. Examples of such services and information include Call Control, SMS/MMS service, as well as network information such as the base station ID that a mobile terminal is currently attached to, neighbour list and active/passive set. In addition to the interfaces provided by the OS, Java (J2ME) also provides a wide set of standardized interfaces which enable a Java application to obtain access to the services and information associated with mobile terminals.
Since implementing services as user plane based services, rather than control plane based services, typically results in lower investment cost and shorter time to market, OMA have standardized service enablers based on user plane signaling. One example of this is user plane based positioning standardized in OMA Secure User Plane Location (SUPL). In SUPL a SUPL client in the terminal accesses network information and positioning capability. The client may communicate with a SUPL Server using IP and a provisioned IP address. As a consequence of the application in the user plane being able to freely access the network information in the conventional terminals, it is possible for a third party to monitor and create mappings of the network topology to the geographical position of the terminals, i.e., outside of the network owner's technical and economical domain.
Thus, when information such as the Cell-ID is available to applications in the user plane, other actors than the operator can monitor and register the information and use it to compete with the operator, for example, to gain business advantages. One example of such competitive use is that of independent actors (not related or in a relationship with the operator) providing user positioning services and statistics, using the operator's infrastructure. Another competitive use is that of competing operators monitoring and keeping registers of competing operator's network infrastructure for business intelligence. In addition to these commercial examples, there are also some countries in which the information, such as cell planes, is supposed to be kept secret due to national security reasons. As the information as such, e.g. the Cell-ID, often is used in a large number of nodes and systems in the operators network (e.g. access and routing control, user management and charging etc.), this information should be properly controlled by the operator to be available to the permitted services and/or clients and also to the equipment within the network.
Accordingly, it would be desirable to provide devices, systems and methods that avoid the afore-described problems and drawbacks.